home *** CD-ROM | disk | FTP | other *** search
/ Die Ultimative Software-P…i Collection 1996 & 1997 / Die Ultimative Software-Pakete CD-ROM fur Atari Collection 1996 & 1997.iso / a / a_funk / packet1.tos / NETROM_I.NF / NR_FRACK.DOC < prev    next >
Encoding:
Text File  |  1987-11-07  |  5.1 KB  |  105 lines
  1.  
  2. PACKET-ACCESS  FROM DC4OX  01.08.87 08:29 UTC   3438 Bytes
  3. FRACK und die Folgen
  4.  
  5. So, anbei gleich mal das erste Beispiel, wie diese Rubrik aussehen kann.
  6.  
  7.  
  8. Eine in den letzten Tagen oft gehoerte Aeusserung :
  9.  
  10. "Ich kann mit NET/ROM keinen Vorteil feststellen, es sind doch viel
  11. mehr Pakete als frueher in der Luft ... "
  12.  
  13. Ja, es sind wirklich viel mehr Pakete als frueher in der Luft, aber nicht,
  14. weil Verbindungen nun mit NET/ROM auf einmal viel mehr Pakete benoetigen.
  15. Ein Grund liegt sicher bei den Kommandos, die ein NET/ROM-Digi alle
  16. abzuarbeiten hat, ein weiterer Grund in der "heissen" Anfangsphase, wo sich
  17. alle erstmal auf das "Neue" stuerzen und alles ausgiebig ausprobieren.
  18.  
  19. Aber der wichtigste Grund, wieso die Luft zu "brennen" scheint, liegt
  20. woanders, naemlich beim sogenannten oder auch "FRACK".
  21. Ich meine hier nicht das bei Schuetzenfesten oft getragene Kleidungsstueck,
  22. sondern den Parameter, den man bei allen TNC's/Softwareloesungen und auch
  23. an den NET/ROM-Digis einstellen kann.
  24.  
  25. FRACK - "FRame ACKnowledge" - legt die Anzahl der Sekunden zwischen
  26. Wiederholungen bei nichtbestaetigten Paketen fest. Oder zwischen den
  27. Nachfragen, was denn nun angekommen ist (Poll's). Werden "normale"
  28. Digipeater benutzt, dann errechnet sich die Anzahl der Sekunden durch
  29.  
  30. (Anzahl der Digipeater * 2  +  1)  *  FRACK .
  31.  
  32. Ein Beispiel. Ich bin mit meinem Nachbarn ohne Digipeater verbunden. Er hat
  33. FRACK auf 3 stehen. Er sendet mir ein Paket, das wegen einer Stoerung bei
  34. mir nicht ankommt. Nach 3 Sekunden fragt sein TNC nach, ob das Paket bei
  35. mir ankam. Wurde auch die Nachfrage gestoert, fragt er nach weiteren
  36. 3 Sekunden erneut nach. Nun connecte ich meinen Nachbarn ueber einen
  37. Digipeater, wieder sendet er ein Paket, was ich nicht richtig empfange.
  38. Jetzt fragt sein TNC nach (1 * 2 + 1) * 3 = 9 Sekunden nach. Arbeite ich
  39. ueber 2 Digipeater, dann sind es schon (2 * 2 + 1) * 3 = 15 Sekunden.
  40.  
  41. Das ist im uebrigen auch der Grund, wieso eine Verbindung ueber Digipeater
  42. durch Direktverbindungen ohne Digipeater viel eher gestoert wird, als eine
  43. Direktverbindung von einer Verbindung ueber Digipeater.
  44.  
  45. Wer jetzt FRACK genau nachmisst - so wie oben beschrieben stimmt es nicht
  46. ganz. Damit es bei Kollisionen nicht genau immer wieder nach derselben
  47. Wartezeit bei den "Kollidanden" zu einer erneuten Kollision kommt, wird
  48. die errechnete Wartezeit noch mit einer Zufallszahl behandelt, so dass
  49. nach einer Kollision die daran beteiligten Stationen es nicht gleichzeitig
  50. erneut versuchen.
  51.  
  52. Der Effekt ist aber klar :  Verbindungen mit NET/ROM-Digis sind ja
  53. Direktverbindungen, also Verbinungen mit Wartezeit FRACK ohne
  54. Digipeaterdraufrechnung. Das heisst, statt Wartezeit 9 Sekunden wie im
  55. Beispiel, nur noch 3 Sekunden. Und das nicht nur bei einer Verbindung,
  56. sondern bei allen Verbindungen ueber den NET/ROM-Knoten. Und das nicht nur
  57. bei einem "Link" pro Verbindung, sondern bei zwei "Links" (zum NET/ROM Knoten
  58. hoch, und vom NET/ROM-Knoten herunter).
  59. Klar, dass dabei dann die Luft brennen muss.
  60.  
  61. Klar sollte jetzt auch sein, dass man allgemein FRACK hoch setzen sollte. Ein
  62. Vorschlag waere 4. Das ist dann immer noch schneller, als wenn man frueher
  63. mit Kamikaze-FRACK 2 ueber einen Digi arbeitete, denn 4 ist kleiner als
  64. (1 * 2 + 1) * 2 = 6. Ausserdem benutzt 4 im Normalfall auch der NET/ROM-
  65. Knoten (Parameter 17 beim PARMS-Kommando).
  66.  
  67. 73, Michael, DC4OX @ DF3AV.
  68.  
  69.  
  70. PACKET-ACCESS  FROM DC4OX  08.08.87 21:42 UTC   1757 Bytes
  71. FRACK UND ZUFALL - UND KEINER HAT'S BEMERKT ...
  72.  
  73. Moin Moin.
  74.  
  75. Anbei noch eine Korrektur zu einigen FRACK-Beschreibungen, die
  76. ich in vorherigen Rubriken machte. Im Eifer der Tipperei habe ich irgendwo
  77. den Einfluss einer Zufallszahl auf FRACK masslos uebertrieben.
  78.  
  79. FRACK berechnet sich bei NET/ROM (bei anderen TNC's aehnlich) so,
  80. dass eine Zufallszeit (0 bis 2,5 Sekunden) addiert wird,
  81. und nicht so, dass mit einer Zufallszahl <= 1 multipliziert wird.
  82. Multiplizieren mit einer Zufallszahl <= 1 waere auch ziemlicher Kokolores,
  83. weil dann reale FRACKS nah bei 0 herauskommen koennten, die Unsinn hoch drei
  84. ausloesen wuerden. Ich verwechselte das im Eifer des Schreibens wohl
  85. mit einem anderen NET/ROM-Internen Parameter ...
  86.  
  87. Die Aussagen ueber FRACK allerdings werden davon natuerlich nicht betroffen.
  88. Inzwischen hat sich nach mehreren Tagen Betriebserfahrung mit NET/ROM
  89. ergeben, dass ein FRACK von 4 beim Betrieb mit NET/ROM eher zu niedrig ist,
  90. und es einiges hoeher anzusetzen ist fuer optimalen Betrieb bei vielen
  91. Stationen.
  92.  
  93. Interessant erscheinen aber auch Experimente mit DWAIT. Das hat zwar beim
  94. Betrieb mit NET/ROM nicht mehr die eigentliche Bedeutung, aber es waere
  95. mal einige Experimente wert, mit diesem Parameter beim User zu
  96. experimentieren. Es scheint, als ob durch hohe Werte dieses Parameters bei
  97. allen Usern auch eine Durchsatzsteigerung zu erreichen ist.
  98.  
  99. Das Dumme an der Sache ist allerdings, dass solche Experimente nur dann
  100. Aussagekraft haben, wenn sich  a l l e  beteiligen.
  101. Bei einem allein wuerden sich Vergroesserungen des Parameters als
  102. ziemlich nachteilig herausstellen ...
  103.  
  104. Trotzdem guter Hoffnung, 73, Michael, DC4OX @ DF3AV.
  105.